SCSM - Resolve the Dreaded “MonitoringHost.exe will not start” Error for good

Blog Admin • 28 August 2018

Resolve the Dreaded “MonitoringHost.exe will not start” Error for good


This issue seems to be around a lot especially with workarounds and solutions which may vary depending on which one works.

There are multiple fixes for this alongside a solution which I have implemented which seems to get it working 100% and also future references which will allow you to avoid this issue before it’s too late.

Symptoms

Mainly the “MonitoringHost.exe” process which it may show as this or shown as “System Center Management Service Host Process” will not show within the Task Manager processes.

And if you try to manually execute it in “%ProgramFiles%\Microsoft System Center\Service Manager\MonitoringHost.exe” , it will run for approximately 15 seconds and then just drop.

Workflows will be affected by this and will cease to work if creating any work items to be processed. And in my case, all of the Connectors stopped working and every time you click to synchronize it will not update.

You will see events in the OperationsManager event log showing the connector starting and ending within the same second, and the OperationsManager CI Connector will also just start whether it has an out of date or received new data configuration.

Work Around 1 - Clear HealthState Service

  • Stop the System Center Management Service
  • Go into %ProgramFiles%\Microsoft System Center\Service Manager\Health Service State and delete everything inside.
  • Then start the System Center Management Service and look into the Task Manager again and see if they are now showing

Also try to run the MontoringHost.exe from an elevated command line.

Work Around 2 - Validate the Workflow Account credentials

Make sure that your workflow account has local administrator rights on the Management Server.

Solution Pre-requisites – Remove Orphaned Connectors (if not working or running and ending)

For the connectors that don’t work or cannot be configured again you will need to remove these as they are now considered to be orphaned connectors.

The SMLets which can be downloaded here https://github.com/SMLets/SMLets/releases

This will allow you to remove the connectors by using the following commands;

To get a list of your connectors use the following command after importing the SMLets module

Get-SCSMObject –Class (Get-SCSMClass –Name Microsoft.SystemCenter.Connector)

Then to remove them enter the following command

Get-SCSMObject –Class (Get-SCSMClass –Name Microsoft.SystemCenter.Connector) | ?{$_.DisplayName –eq “<Connector Name>”} | Remove-SCSMObject –Force –Confirm


Solution 1 - Check the SCOM Agent Settings within Service Manager Management Server

When I looked into the Control Panel – System and Security – Microsoft Monitoring Agent I noticed that this was blank as I had set this up initially for the SCOM server to monitor its services.

So, I went into the settings and added a connection to my SCOM Management Server which will automatically restart the System Center Management Service and Microsoft Monitoring Agent Service.

After that all of the “System Center Management Service Host Process” processes appeared and all of my workflows start to work again.

Solution 2 – Re-import the Service Manager Linking Framework Configuration

Check if this management pack is missing, as this is normally the main cause for the connectors not to work at all. If missing (and also if not) you can try to re-import this unsealed management pack as this contains the configuration of any connector you create within SCSM.

It should be located in your installation folder on “C:\Program Files\Microsoft System Center\Service Manager\ServiceManager.LinkingFramework.Configuration”

Future Reference

These best practices are the best ways to ensure that you do not see this issue or ensure that you no longer face this issue again

  • These issues can normally happen if you attempt to remove or do too many updates to the “Service Manager Configuration Management Library” which is default MP it goes to when creating any custom objects. As best practice when creating any custom views or any custom objects ensure that you create a New Management pack which contains these settings, it makes the dependency a lot easier to manage in case of any issues in which you need to remove any management packs and face a complication in which foundational management packs would have to be removed in order to re-import back
  • Rebuilding SCSM using the same database will not work at all. However, you can build a secondary Management Server and switch over the primary function to the secondary which is also a good workaround, but to have a dud Service Management Server within the hierarchy can cause later issues
  • Create a backup schedule for your Service Manager and Data Warehouse databases alongside side the encryption keys so that you have a baseline marker if this issue was to occur again.


Your business can become more effective with system centre automation. Get in touch with Walsham Solutions for your system centre training today.

Microsoft Endpoint Manager: In-Place Upgrade or Side by Side Part 4 - SQL Server Requirement Analysis

by D Walsham • 13 December 2021
Looking through the current SQL Server topology and how it affects our decision

Microsoft Endpoint Manager: In-Place Upgrade or Side by Side Part 3 - Current Branch Upgrade Approaches

by D Walsham • 19 November 2021
Impact of Current Branch Upgrades

Microsoft Endpoint Manager: In-Place Upgrade or Side by Side - Part 2 - Operating System Considerations

by D Walsham • 29 October 2021
Introduction

Microsoft Endpoint Manager: In-Place Upgrade or Side by Side

by D Walsham • 7 October 2021
Introduction

Endpoint Manager: Device Estate Cleanup

by D Walsham • 6 October 2021
Introduction

Modern Workplace Management: Creating Applications Common Practices - LOB vs Win32 Package

by D Walsham • 3 September 2021
Introduction

Modern Workplace Management: Build Endpoints Without SCCM Part 6

by D Walsham • 12 August 2021
All the parts of the series we went into great detail about how we analyse an end to end solution and how we would design a solution in which would allow us to build endpoints without SCCM being a dependency. Whilst we did this, there is another scenario which we have not touched on yet, which is the hybrid scenarios. In a perfect world ideally you would have your Azure Active Directory within the cloud, every machine meets the recommended requirements for Windows 10, everything is imported into Intune/Autopilot and everyone is happy. But we know this isn't realistic in all cases. Many organisations cannot just simply up and go from on-premise into the cloud therefore the checkpoint here is of course getting into hybrid solutions such as; Co-Management Between Intune and SCCM Hybrid AD with Azure AD and On-Premise AD syncing together These things can play a very interesting part in how you would tackle this if you envisage the next step in the blueprint is to be in a position in which you can build and manage endpoints soley within Intune. With this final part of the series we will go in-depth in how the common hybrid setups look like and how we go about moving into the next step of being able to manage and build devices without SCCM.

Modern Workplace Management: Build Endpoints without SCCM Part 5

by D Walsham • 29 July 2021
In continuation from the previous part where we had discussed how we create the "on site" piece of the solution, this was the part which would allow us to get our endpoints into a state in which they would essentially be ready to go through the Autopilot process. Which leaves our next piece of the puzzle, to begin the configuration of the actual backend side that resides within our Endpoint Management console. And you will see how everything ties up together to satisfy the full end to end process of getting an unknown (or known) device to proceed thorough the whole workflow to be finally managed by Intune without the aid of SCCM taking part in any of the prerequisites or preparation at hand.

Modern Workplace Management: Build Endpoints without SCCM Part 4

by D Walsham • 15 July 2021
In this part we are now going to look into the technical step by step points on how we put everything together. In the previous part we spoke about the structure of how we would asses whether a machine was actually ready to be built with Autopilot or not with a build checklist process which would step through all areas which would cover an endpoints eligibility. Now with everything planned out we finally want to step into making things reality by putting everything together.

Endpoint Manager: Find machines not in Autopilot

by D Walsham • 2 July 2021
When it comes to managing your endpoints in endpoint manager, one of the things you may be looking to do is to get all of your Intune registered machines to also be enrolled as Autopilot devices. Now we can of course just have the deployment profile deployed to all machines and then hit the "Convert targeted machines to autopilot" but this might not necessarily be feasible for every client. We may want to perform some due diligence first so we can at least understand what devices in Intune are not in Autopilot.
Show More